[DebugInfo] Init DwarfVersion of MCOptions like the other. #146666
Conversation
llvmbot
added
clang
|
@llvm/pr-subscribers-clang-codegen @llvm/pr-subscribers-clang Author: Liu Ke (Sockke) ChangesShould the backend's DwarfVersion be initialized like other options? Previously, -gdwarf-xxx did not take effect in the backend—was there a specific reason for this? Full diff: https://github.com/llvm/llvm-project/pull/146666.diff 1 Files Affected:
diff --git a/clang/lib/CodeGen/BackendUtil.cpp b/clang/lib/CodeGen/BackendUtil.cpp
index 1c92ea45c7458..9cee6281a43f6 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -486,6 +486,7 @@ static bool initTargetOptions(const CompilerInstance &CI,
break;
}
+ Options.MCOptions.DwarfVersion = CodeGenOpts.DwarfVersion;
Options.MCOptions.SplitDwarfFile = CodeGenOpts.SplitDwarfFile;
Options.MCOptions.EmitDwarfUnwind = CodeGenOpts.getEmitDwarfUnwind();
Options.MCOptions.EmitCompactUnwindNonCanonical =
|
|
I guess this would be visible when using clang to compile some assembly code and requesting debug info of a specific version? Is that the case? Could you add a test case showing that this has a/the desired effect? |
Sockke
requested review from
DeinAlptraum,
rupprecht,
keith,
aaronmondal,
aaupov,
maksfb,
rafaelauler,
ayermolo,
yota9,
paschalis-mpeis,
antiagainst,
kuhar,
hanhanW,
nicolasvasilache,
banach-space,
dcaballe,
Groverkss,
matthias-springer,
JDevlieghere,
lanza and
bcardosolopes
as code owners
Sockke
removed request for
a team,
nikic,
keith,
antiagainst,
rupprecht,
JDevlieghere,
aaupov,
paschalis-mpeis,
matthias-springer,
banach-space,
kuhar,
hanhanW,
bcardosolopes,
maksfb,
rafaelauler,
nicolasvasilache,
lanza,
yota9,
dcaballe,
aaronmondal,
ayermolo,
DeinAlptraum and
Groverkss
|
Sorry for the noise - wrong reviewers were tagged by mistake. |
We have pre-built bitcode. When compiling bitcode, we need to request specific debug info version - like Distributed ThinLTO's backend process - to keep version consistency. |
| // RUN: %clang -target x86_64-linux-gnu -gdwarf-4 -S -emit-llvm -o - %s \ | ||
| // RUN: | %clang -target x86_64-linux-gnu -g -x ir -c -o - - \ | ||
| // RUN: | llvm-dwarfdump -v - \ | ||
| // RUN: | FileCheck %s --check-prefix=SINGLE-5 |
There was a problem hiding this comment.
Is this actually the behavior we want? Normally, I'd expect bitcode files to already have a version specified; when clang generates LLVM IR, it generates the DWARF version as metadata. This patch explicitly overrides that version in favor of whatever is specified on the command-line when the bitcode is lowered to asm.
Overriding the version won't really work right, anyway: clang generates different debug info depending on the version it's targeting.
There was a problem hiding this comment.
Is this actually the behavior we want? Normally, I'd expect bitcode files to already have a version specified; when clang generates LLVM IR, it generates the DWARF version as metadata. This patch explicitly overrides that version in favor of whatever is specified on the command-line when the bitcode is lowered to asm.
DwarfDebug::DwarfDebug(AsmPrinter *A)
...
unsigned DwarfVersionNumber = Asm->TM.Options.MCOptions.DwarfVersion;
unsigned DwarfVersion = DwarfVersionNumber ? DwarfVersionNumber
: MMI->getModule()->getDwarfVersion();
...
Dwarf64 &=
((Asm->TM.Options.MCOptions.Dwarf64 || MMI->getModule()->isDwarf64()) &&
TT.isOSBinFormatELF()) ||
TT.isOSBinFormatXCOFF();The effective value of DwarfVersion was designed to let MCOptions override the metadata, including Dwarf64. However, unlike other options, DwarfVersion was not initialized by CodeGenOpts.
Overriding the version won't really work right, anyway: clang generates different debug info depending on the version it's targeting.
Sorry, could you please explain in detail why it's not working properly?
There was a problem hiding this comment.
(Thanks for the test case)
(I'd like to hear more of @efriedma-quic's perspective/understanding to be sure)
Though I think for LTO - I believe the metadata already gets min/maxed (whichever way we do that - ah, it's "Max" - so if you have IR bitcode that's DWARFv4 and some that's DWARFv5 and you IR link it, you get DWARFv5 across the board) - so DWARF metadata emitted for 4 can end up emitted as 5 at least... going backwards might be less well/not at all tested, though...
Not sure what the right direction is here, then.
There was a problem hiding this comment.
Overriding the version won't really work right, anyway: clang generates different debug info depending on the version it's targeting.
Sorry, could you please explain in detail why it's not working properly?
clang CodeGen has checks for the target DWARF version. If clang generates v5 DWARF and you override it to v4, you won't get the same result you would if you originally generated v5. Which could mean debuggers get confused by the resulting DWARF.
Should the backend's DwarfVersion be initialized like other options? Previously, -gdwarf-xxx did not take effect in the backend—was there a specific reason for this?